自愈疗效

1. 非工作时间运维人员处理报警以及响应时间;

2. 减少出现报警直接去线上操作的次数，毕竟少上一次服务器就少一次风险;

3. 提高运维人员对报警的分析能力、以及高度的业务理解;

4. 提升运维人员自身价值。

回顾往昔

还记得之前做监控岗的时候，上班每天都要接收很多的Nagios、自定义监控等发出的报警邮件，然后再手动去处理系统的各种报警，在报警多的时候那个郁闷呀，特别是值夜班的时候可能打个盹的功夫磁盘就爆了，影响到服务器上的服务了有木有。

当然我们可以写各种自动化处理脚本去自动检测执行，但无奈场景、服务器之多，又加上脚本的分散性维护，不能很连贯的处理现有场景报警，只能傻瓜式的去处理报警，重复性劳动比较多。对于怎么能智能、优雅的去处理报警和报警高级自愈，是体现出一个运维更具价值的东西，毕竟平台稳定性高、故障率低是运维生存的根本。

故障自愈（换言之就是故障自动愈合）在这方面正好能解决我们的一些痛点（升职加薪、迎娶白富美必备之良品），通过自定义各种套餐场景（故障处理场景），然后调用作业平台去处理当前环境的各种报警，话说只要你的功夫好（脚本），没有它处理不了的报警。故障自愈能极大节省运维投入的时间成本，省下来的时间撩妹、电竞、陪女盆友看你啰。

蓝鲸之缘

刚接触蓝鲸还是在16年的GOPS运维大会上，到现在使用蓝鲸平台已经1年多的时间，尤其是本次的3.1版本系列，在各方面都比之前的初始版本有很大的提升，本次我要分享的重点不是蓝鲸平台本身，而是其中的一个SAAS（故障自愈），当初在看到3.1版本介绍的时候，也是被它给吸引了。

到现在升级3.1版本到现在使用快3个月了，环境升级完之后就开始着手故障自愈的研究使用，到现在使用来说，谈不上有多深的应用经验， 但是它目前覆盖了我这边部分基础监控报警的自愈处理，下面就以自身环境的故障自愈使用情况分享给大家，希望有所帮助。

说了很多废话哈，开始进入正题！！！

我的自愈

切身收益：没上自愈之前可能每天平均会花在处理基础报警上1小时左右，上完自愈之后，每天只需要花5分钟不到时间看自愈处理结果即可。同时平均每天处理报警25+左右。

报警源：关于报警源，蓝鲸目前支持原生的蓝鲸监控、Zabbix监控、Open-Falcon监控、Nagios监控以及REST API自定义推送等，这里需要根据自身的实际情况来选择，这是要实现”无人值守”的最根本条件哈。

怎么将自身环境的监控应用到蓝鲸自愈上呢？（Zabbix） 

在未启用监控产品中找到Zabbix，选择启用，然后按照提示完成操作，如下所示完成报警源启用

报警类型解释：这里的报警类型就是后续要和监控平台中的监控项做匹配的，这样才能进行根据不同规则定义不同的自愈场景，也有可能需要自己新增报警类型，如下

Zabbix监控项里面的key值如下，部分展示

接入后效果：

到这里，算是完成Zabbix监控条目的匹配引入，但是现在自愈还不会处理你报警系统推送的报警条目，接着我们按照故障自愈之旅实现所有功能。

故障自愈之旅

接入一个自愈快捷套餐

点击接入自愈-接入自愈-然后填写相应的信息，对于自愈的处理选择已有的快捷处理套餐，更新通知方式及通知人员，然后命名启用保存。

完成一个自愈套餐的执行

Zabbix报警自动推送报警条目到FTA，然后FTA根据我们上面接入好的自愈类型匹配，然后自动执行相应的快捷自愈套餐，下面是根据报警自动获取占用内存TopN的进程发送消息出来。

创建一个自愈套餐

点击套餐管理-创建自愈套餐-然后选择相应的套餐类型，这里目前分为快捷套餐类（系统自带）和周边系统类（作业平台调用，需要自定义作业来配合处理），填写完相关报警即可提供给接入自愈来应用。

创建收敛规则

点击高级配置-报警收敛-新建收敛规则，然后根据选项填写保存。

如下如所示：TCP端口检测，相同主机下1分钟4条报警就采用成功后跳过的收敛方式处理。

上面创建完成后，接下来还要接入自愈，这个收敛规则才能生效，如下：

创建一个对接作业平台的套餐

首先作业平台中，作业执行里面新建一个作业，来保存为常用作业执行，这个作业要实现的功能就根据你想处理什么样的报警而定的，假如我想处理磁盘报警，就需要写一个Linux下通用的文件处理脚本（”/var/logs/nginx” “10” “*.log”，清理/var/logs/nginx目录下10天前的log结尾的日志）

故障自愈-套餐管理里面创建相应的自愈处理套餐

故障自愈-接入自愈里面创建相应的接入自愈保存后即完成作业平台的调用。

小结

通过以上介绍，大家有没有对故障自愈的应用操作了解一些，另外在我当前的环境故障自愈已经覆盖了Zabbix的磁盘报警（就磁盘报警来说处理场景就不下5种）、内存报警、Swap分区报警，后续还在不断的增加更新。从上了自愈之后，我再也不用半夜起来，就为了处理一个磁盘报警、回收一下服务器内存。后续大家如果有在自愈方面有什么需要协助和交流的可以联系我，大家一起进步。

其它

• 产品白皮书

• 官方当Zabbix遇见自愈

• 测试邮件服务是否正常

下面是我当前环境的部分真实取图：

自愈套餐

接入自愈情况

自愈处理通知情况

案例分享

报警类型：vm.memory.size报警处理方式：自动回收集群服务器上内存占用TopN的进程资源思路：由于我当前的环境是一批集群服务器，上面跑的Spark、Hadoop等服务，前期我们事先对这批服务器进行资源观察对比，发现占用Top5的基本都是Spark的Executor子进程，所以我就开发一个脚本，报警触发后会获取当前服务器Executor进程，然后进行优雅的重启来释放一直占用的内存，缓解集群资源压力。 

实现步骤：

1. 先写好进程处理脚本，在作业平台保存为 “常用作业执行”

2. 在故障自愈里面建立相应的故障套餐，应用刚才作业平台创建好的作业，脚本传参根据自己脚本而定

3. 然后根据实际情况接入自愈场景

写在最后

如果你还在为天天手动处理大量重复性报警而烦恼吗，那么推荐你赶快接入蓝鲸故障自愈平台，它将解放你的双手，实现报警无人值守，让你有更多的时间去为维护业务稳定性做准备。

温馨提示： 

1.蓝鲸社区版V3.1包含故障自愈后台（FTA） 
2.SaaS包在市场下载：http://bk.tencent.com/s-mart/ 
3.有问题请联系蓝鲸客服QQ: 800802001

4.欢迎投稿蓝鲸，分享你的运维干货，更有福利领取，点击“查看详情”。